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(57) ABSTRACT 

The present invention discloses a central certificate man- 
agement system for thin client devices in data networks and 
has particular applications to systems having a large number 
of the thin clients serviced by a proxy server through which 
the thin clients communicate with a pluraUty of secure 
server computers over a data network. According to one 
aspect, the present invention provides a certificate manage- 
ment module that causes the server device to manage digital 
certificates for each of the thin client devices. To minimize 
the latency of obtaining certificates for each of the thin cHent 
devices, the certificate management module reserves a fixed 
number of free certificates signed by a certificate authority 
and their respective private keys in a certificate database and 
frequently updates the free certificate according to a certifi- 
cate updating message. Whenever a user account is created 
for a thin client device, the certificate management module 
fetches one or more free certificates from the certificate 
database and associate the fetched certificates to the created 
account and meanwhile the certificate management module 
creates new free certificates with the certificate authority lo 
fill in the certificate database. Apart from the tradition of 
obtaining certificates locally in client devices that normally 
have sufficient computing power, the present invention uses 
the computing resources in a server device to cany out the 
task of obtaining and maintaining certificates asynchro- 
nously in the proxy server and further. These and other 
features in the present invention dramatically minimize the 
demands for computing power and memory in thin client 
devices like mobile devices, celltilar phones, landline tele- 
phones or Internet appliance controllers. 
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CENTRALIZED CERTIFICATE 
MANAGEMENT SYSTEM FOR TWO-WAY 
INTERACTIVE COMMUNICATION DEVICES 
IN DATA NETWORKS 

REFERENCE TO A "MICROFICHE APPENDIX" 

Appendix A, which is a part of the present disclosure, is 
a microfiche appendix entitled "Centralized Certificate Man- 
agement System for Two-way Communication Devices in 
Data Networks" consisting of 2 sheets of microfiche having 
a total of 184 frames. The microfiche Appendix is a source 
code listing of one embodiment of the centralized certificate 
management system for two-way interactive communication 
devices over a wireless data network in the present 
invention, which is described more completely below. 

A portion of the disclosure of this patent document 
contains material, that includes, but is not limited to. Appen- 
dices A, B and C, which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Ofi&ce 
patent file or records, but otherwise reserves all copyrights 
whatsoever. 

BACKGROUND OF THE INVENTION 

1. Field of Invention 

The present invention relates to data security between 
server computers and client computers in data networks, and 
more particularly relates to systems for managing, in a proxy 
server computer, digital certificates for two-way interactive 
communication devices over the data networks; wherein the 
two-way interactive communication devices, such as mobile 
devices, cellular phones, landline telephones and Internet 
appliance controllers, have generally limited computing 
resources such as computing power, memory and graphical 
display capability. 

2. Description of the Related Art 

A fast-growing trend on the Internet is electronic com- 
merce. The electronic commerce is an integrative concept 
designed to draw together a wide range of business support 
services, trading support systems for commodities, products, 
customized products and custom-built goods and services; 
ordering and logistic support systems; settlement support 
systems; and management information and statistical report- 
ing systems, all via the Internet. It is well known, however, 
that the Internet is a wide open, public and international 
network of interconnected computers and electronic devices 
around the world. The ability to send and receive secure data 
becomes a fundamental requirement in conducting elec- 
tronic commerce over the Internet. To transact business over 
the open network, a business or organization must have an 
efficient and reliable manner to establish its identity and 
credibility to protect itself and its customers from imposters. 
Similarly, customers need assurance that their private infor- 
mation they may submit over the Internet can not be read by 
anyone but the business that they submit to. 

One of the on-going efforts to ensure private communi- 
cations or business transactions between two authenticated 
parties is to use digital certificates to bind the identities of 
the two parties to a pair of electronic keys that can be used 
to encrypt and sign digital information transmitted over the 
Internet. A digital certificate makes it possible to verify 
someone's claim that they have the right to use a given key, 
which helps prevent others from using phony keys to 
impersonate authorized users. Used in conjunction with 
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encryption, digital certificates provide a more complete 
security solution by assuring the identity of all parties 
involved in a transaction through an open network. 

The current architecture for using the digital certificates is 
binding between two computers, one being a client com- 
puter and the other being a server computer, on the Internet, 
that means both computers physically hold their own 
certificates, requiring a memory space to keep certificates. In 
case, one of the certificates becomes invalid (expired, 

10 revoked or no longer usable), the computer that owns the 
invalid certificate may acquire a new certificate from a 
certificate issuing authority. However, the acquiring process 
generally takes a number of minutes and a significant 
amount of computing power. When a communication scs- 

15 sion between the two computers is established, the two 
computers authenticate each other by examining the coun- 
terpart's certificate. A session key is created when the 
authentication is successful and a secure communication 
session thus commences using the session key to encrypt all 
information exchanging between the two computers. The 
authentication process also takes a significant amount of 
computing power. 

When the client computer is a small two-way communi- 
cation device such as a mobile computing device, a cellular 

^ phone, a landline telephone, or an Internet appliance 
controller, the above architecture is hardly applicable. To 
increase the portability and mobility, most of such two-way 
communication devices are designed small in size, light in 
weight, low in power consumption and as economically as 
possible. Such designs, often considered as thin-client 
designs, result in a very limited computing power, typically 
equivalent to less than one percent of what is provided in a 
typical desktop or portable computer and the memory capac- 
ity thereof is generally less than 250 kilobytes. That means 
that the thin client devices would not have extra memory 
spaces to store a number of certificates and the required 
computing power to acquire a new certificate in real time if 
one of the possessed certificates becomes invalid. There is 
thus a great need for providing the thin clients with a 
mechanism to effectively manage the certificates. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features, aspects, and advantages of the 
45 present invention will become better understood with regard 
to the following description, appended claims, and accom- 
panying drawings where; 

FIG, 1 illustrates, as an exemplary illustration, how the 
certificates are being used between a client device and a 
merchant server; 

FIG. 2 illustrates a schematic representation of a mobile 
data network comprising an airnet and a landnet, in which 
the present invention may be practiced; 
55 FIG. 3 illustrates a representation of the present invention 
interacting with other parts or components in the data 
network; 

FIGS. 4Aand 4B demonstrate an example in which a user 
of a mobile device requests certificates from a user-specified 
CA; 

FIG. 5 depicts a block diagram of various components in 
a certificate management module in the present invention; 
and 

65 FIGS. 6A and 6B illustrate an operation flowchart show- 
ing processes and procedures for managing certificates in a 
server device for thin clients over a data network. 
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DETAILED DESCRIPTION OF THE key. In public key encryption, the public key is made 

INVENTION available to anyone who wants to correspond with the owner 

Notation and Nomenclature of the key pair. The public key can be used to verify a 

In the following detailed description of the present message signed with the private key or encrypt messages 

invention, numerous specific details are set forth in order to s that can only be decrypted using the private key. The 

provide a thorough understanding of the present invention. security of messages encrypted this way relics on the 

However, it will become obvious to tbose skilled in the art security of the private key, which must be protected against 

that the present invention may be practiced without these unauthorized use. 

specific details. In other instances, well known methods, The key pair in a certificate is bound to a user's name and 

procedures, components, and circuitry have not been lo other identifying information. When installed in Hyper Text 

described in detail to avoid unnecessarily obscuring aspects Markup Language (HTML) browser, such as Netscape 

of the present invention. Navigator from Netscape Communication Inc. in California 

The detailed description of the present invention in the or Internet Explorer from Microsoft Corporation of 

following are presented largely in terms of procedures, Richmond, Wash., the certificate functions as an electronic 

steps, logic blocks, processing, and other symbolic repre- 15 credential that sites being contacted can examine. This 

sentations that resemble of data processmg devices coupled sometimes enables digital certificates to replace password 

to networks. These process descriptions and representations dialogs for information or services that require membership 

are the means used by those experienced or skilled in the art or restrict access to particular users. For example, when one 

to most effectively convey the substance of their work to sends messages to a merchant web site, he signs the mes- 

others skilled in the art. The present invention is a central- 20 sages and encloses his digital ID to assure the recipient of 

ized certificate management system for two-way interactive the message that the message was actually sent by him. 

communication devices in data networks. The method along When the merchant receives digitally signed messages, the 

with the architecture to be described in detail below is a signer's digital ID is verified to determine that no forgery or 

self-consistent sequence of processes or steps leading to a false representation has occurred. Generally, once a user 

desired result. These steps or processes are those requiring 25 obtains a certificate, he can setup his security-enhanced web 

physical manipulations of physical quantities. Usually, or e-mail application to use the certificate automatically, 

though not necessarily, these quantities may take the form of FIG. 1 illustrates the authentication process using the digital 

electrical signals capable of being stored, transferred, IDs between the client and the merchant server, 

combined, compared, displayed and otherwise manipulated The most secure use of authentication involves enclosing 

in a computer system or electronic computing devices. It 30 one or more certificates with every signed message. The 

proves convenient at limes, principally for reasons of com- receiver of the message wotild verify the certificate using the 

mon usage, to refer to these signals as bits, values, elements, certifying authority's public key and, now confi^dcnt of the 

symbols, operations, messages, terms, numbers, or the like. public key of the sender, verify the message's signature. 

It should be borne in mind that all of these similar terms are There may be two or more certificates enclosed with the 

to be associated with the appropriate physical quantities and 35 message, forming a hierarchical chain, wherein one certifi- 

are merely convenient labels applied to these quantities. cate testifies to the authenticity of the previous certificate. At 

Unless specifically stated otherwise as apparent from the the end of the certificate hierarchy is a top-level certifying 

following description, it is appreciated that throughout the authority, which is trusted without a certificate from any 

present invention, discussions utilizing terms such as "pro- other certifying authority. The public key of the top-level 

cessing*' or "computing" or "verifying" or "displaying" or 40 certifying authority must be independently known, for 

the like, refer to the actions and processes of a computing example, by being widely published. In other words, a 

device that manipulates and transforms data represented as sender whose company is known to the receiver may need 

physical quantities within the computing device's registers to enclose only one certificate (issued by the company), 

and memories into other data similarly represented as physi- whereas a sender whose company is unknown to the receiver 

cal quantities within the computing device or other elec- 45 may need to enclose two or more certificates. For higher 

tronic devices. grade of security, it is a common practice to enclose just 

Introduction to Digital Certificates enough of a certificate chain so that the issuer of the highest 

A digital certificate or certificate, sometimes referred as level certificate in the chain is well known to the receiver. If 

digital ID or security certificate, is a piece of information, there arc multiple recipients, then enough certificates should 

often stored as a text file, to be used by the secure sockets 50 be included to cover what each recipient might need, 

layer (SSL) protocol to estabUsh a secure connection The Preferred Embodiment 

between two parties over an open data network. In the Refenring now to the drawings, in which like numerals 

simplestfonn, a certificate contains a public key and a name. refer to like parts throughout the several views. FIG. 2 

As commonly used, a certificate also contains an expiration illustrates a schematic representation of a data network 100 

date, the name of the certifying authority that issued the 55 in which the present invention may be practiced. The data 

certificate, a serial number, and perhaps other information. network 100 comprises an aimet 102 that is generally called 

Most importantly, it contains the digital signature of the wireless network and a landnet 104 that is generally a 

certificate issuer, i.e. an encrypted "fingerprint" that can be landline network, each acting as a communication medium 

used to verify the contents of the certificate. for data transmission therethrough. The airnet 102, in which 

A digital certificate, or simply certificate, is issued by a 60 the data transmission is via the air, is sometimes referred to 

Certification Authority (CA) and signed with the CA's as a carrier network because each aimet is controlled and 

private key. The most widely accepted format for digital operated by a caaier, for example AT&T and GTE, each 

certificates is defined by the CCITT X.509 international having its own communication scheme, such as CDPD, 

standard; thus certificates can be read or written by any CDMA, GSM and TDMA for the airnet 102. The landnet 
application complying with the CCITT X.509 standard. A 65 104 or the Internet, used interchangeably herein, may be the 

digital certificate uses public key encryption techniques that Internet, the Intranet or other private networks. Referenced 

are based on a pair of related keys, a public key and a private by 106 is one of the mobile devices that can be a mobile 
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device, a cellular phone, a landline telephone or an Internet have significantly less computing power and memory. Fur- 
appliance controller, capable of communicating with the Iher it is understood to those skilled in the art that the UDP 
airnet 102 via an antenna 108. It is generally understood that does not require a connection to be established between a 
the airnet 102 communicates simultaneously with a plurality client and a server before information can be exchanged, 
of two-way communication devices, of which only a mobile s which eliminates the need of exchanging a large number of 
device 106 is shown in the figure. Similarly, connected to the packets during a session creation between a client and a 
Internet 104 are a plurality of desktop personal computers server. Exchanging a very small number of packets during a 
(PCs) 110 and a plurality of server computers 112, though transaction is one of the desired features for a mobile device 
only one representative respectively is shown in the figure. with very limited computing power and memory to efifec- 
The PC 110, as shown in the figure, may be a personal lO tively interact with a landline device, 
computer SPL 300 from NEC Technologies Inc. and runs a The mobile device 106 comprises a display screen 116 
HTML Web browser via the Internet 104 using HyperText and a keyboard pad 118. The hardware components includ- 
Transport Protocol (HTTP) to access information stored in ing a microcontroller, a ROM and a RAM in the mobile 
the web server 112 that may be a workstation from SUN phone 106 are known to those skilled in the art and so the 
Microsystems Inc. It is understood to those skilled in the art 15 hardware components are not described in detail herein, 
that the PC 110 can store accessible information therein so With the display screen 116 and the keypad 118, a user of the 
as to become a web server as well. Between the Internet 104 mobile device 106 can interactively communicate with the 
and the airnet 102 there is a proxy server computer 114 proxy server 114 over the airnet 102. According to one 
performing data communication therebetween. The proxy embodiment, one portion of the compiled and linked pro- 
server computer 114, also referred to as link server or 20 cesses of the present invention are stored in the ROM as a 
gateway server computer, may be a workstation or a per- client module that causes the mobile device 106 to operate 
sonal computer and performs mapping or translation with the proxy server 114. Upon activation of a predeter- 
functions, for example, mapping from one protocol to mined key sequence utilizing the keypad 118, the micro- 
another, thereby the mobile device 106 can be in commu- controller initiates a communication session request to the 
nication with any one of the servers 112 or the PCs 110, 25 proxy server 114 using the cUent module in the ROM. Upon 
respectively. establishing the communication session, the mobile device 
One communication protocol used on the Internet 104 is 106 typically receives a single HDML deck from the proxy 
the well known HyperText Transfer Protocol (HTTP) or server 114 and stores the deck as cached in the RAM. As 
HTTPS, a secure version of HTTP. HTTP runs on the described above, an HDML deck comprises one or more 
Transport Control Protocol (TCP) and controls the connec- 30 cards and each card includes the information required to 
tion of a well known HyperText Markup Language Web generate a screen display on the display screen 116. The 
browser, or HTML Web browser in the server 114, to the number of cards in a card deck is selected to facilitate 
Web server 112, and the exchange of information Iherebe- efficient use of the resources in the mobile device 106 and 
tween. HTTPS supports SSL that is used mosdy in secure in the airnet network 102. Generally, one of the cards is a 
and authenticated communications between the HTML 35 choice card shows a sequence of frequently visited web sites 
browsers and web servers. A common notation in the HTML and allows the user to choose one to make a secure and 
browsers is the use of "https'' before a universal resource authenticated communication session with through the 
locator, or URL, which indicates that an SSL connection will proxy server 114. The process of using certificates to estab- 
be established. In an SSL connection one side, preferably the lish such communication session will be described below, 
server side, of the connection shall have a certificate that 4g Referring now to FIG. 3, there is depicted a representation 
must be authenticated by the counterpart side. Each side then of the present invention interacting with other parts or 
encrypts what it sends out using information from either its components in the data networic. Referenced by 302, 304 
own, the other side or both side certificate, ensuring that only and 306 are three representatives of a plurality of the mobile 
the intended recipient can decrypt it, and that the other side devices coupled to the airnet 102, similarly referenced by 
can be sure the data come from the place it claims to have 45 310, 312 and 314 are three representatives of a plurality of 
come from, and that the message has not been tampered landline devices coupled to the landnel 104. The proxy 
^^Ijj server device 128, which can be the one 114 in FIG. 2, 
The communication protocol between the mobile device couples the aimet 102 to the landnet 104, therefore any 
106 and the proxy server 114 via the airnet 102 is Handheld mobile devices can conmiunicate with the landline devices 
Device Transport Protocol (HDTP), or Secure UpUnk Gate- so via the aimet 102, the proxy server 114 and the landnet 104. 
way Protocol (SUGP), which preferably runs on User Data- To facihtate the description of the present invention, the 
gram Protocol (UDP) and controls the connection of a internal block diagrams of the mobile device 302 and the 
HDML Web browser, in the mobile device 106, to the proxy link server 114 are respectively illusU-ated. Other processes 
server 114, where HDML stands for Handheld Device and hardware are known to those skilled in the art and are 
Markup Language. HDML, similar to that of HTML, is a tag 5S not iUustrated in detail in the figure for clarity, 
based document language and comprises a set of commands Each of the mobile devices, such as the one 302, is 
or statements specified in a card that specifies how infor- assigned to a device ID 316. The device ID 316 can be a 
mation displayed on a small screen of the mobile device 106. phone number of the device or a combination of an IP 
Normally a number of cards are grouped into a deck that is address and a port number, for example: 
the smallest unit of HDML information that can be 60 204.163.165.132:01905 where 204.163.165.132 is the IP 
exchanged between the mobile device 106 and the proxy address and 01905 is the port number. The device ID 316 is 
server 114. The specifications of HDTP, entitled "HDTP further associated with a subscriber ID 318 authorized by a 
Specification" and HDML, entitled "HDML 2.0 Language carrier in the proxy server U4 as part of the procedures to 
Reference" are enclosed and incorporated herein by refer- activate the mobile device 302 by establishing a user 
ence in its entirety. The HDTP is a session-level protocol 65 account 324 in the proxy server 114. The subscriber ID 318 
that resembles HTTP but without incurring the overhead may take the form of, for example, 861234567-109()0_ 
thereof and is highly optimized for use in thin devices that pn.mobile.att.net by AT&T Wireless Service. The subscriber 
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ID 318 is a unique identification of the mobile device 302. invention maintains the certificates in a user account in the 

In other words, each of the mobile devices 302, 304 and 306 proxy server. Managing certificates in a proxy server for all 

has its own unique device ID that corresponds to a sub- clients makes it possible for the clients to access any secure 

scriber ID indexing a respective user account in the proxy web sites without demanding additional computing power 

server 114. The following description is based on the mobile 5 and memory. Other advantages will be farther appreciated in 

device 302 and the associated account 324, it will be the description below. 

appreciated by those skilled in the art that the description is The certificates are issued by a CAthat can be any trusted 

equally applied to a plurality of the mobile devices in central administration willing to vouch for the identities of 

communication simultaneously with the proxy server 114. those to whom it issues certificates and their association with 

The account 324, indexed by the device ID 316 or the lo a given key, for example, a company or a university may 

subscriber ID 318 and identified by an address identifier issue certificates to its own employees or its students. To 

such as a URL, is a data structure comprising user info 322, accommodate the need of the mobile device 302 to obtain 

a certificate list 320 and a private key list 326, wherein the certificates from a CA other than the one that the CMM 342 

user info 22 includes the account configuration and other uses to get the free certificates from, the server module 340 

account related information, such as usemame and pass- 15 allows the user thereof to log onto the user account 324 

word. The URL of the account may take the form of, for associated to the mobile device 302 through any computers, 

example, www.attcom/Pocketnet, which indicates that the for example, a PC 314 coupled in the landnet 104. This is 

airnet 102 is operated by AT&T wireless service. The accomplished by logging onto the user account 324 using 

certificate list 320 contains or points to a list of designated the address identifier of the user account 324, for example: 

certificates issued by one or more CAs and the private key 20 www.att.com/Pocketnet. To ensure that the account 324 is 

fist 326 contains a list of keys, each corresponding respec- accessed by an authorized user, a set of credential 

tively to each certificate in the certificate list 320. All information, such as a usemame and password, is required, 

certificates in the certificate list 320 are exclusively associ- The server module 340 through the HTTP module 330 will 

ated with the particular account. Generally the proxy server prompt for the username and password when the user 

114 maintains a large number of such user accounts, pref- 25 connects the PC 314 to the URL using http://www.att.com/ 

erably kept in a database 328, each of the user accounts is Pocketnet. Entries of a pair of matched usemame and 

respectively associated to each of the mobile devices that are password will be granted the permission to access the 

subscribed with the same carrier and serviced by the proxy account. 

server 114. It can be appreciated that the certificates in one To provide flexibiUty and security to the account, the 

account are different from those in other accounts because of 30 usemame and password are fully administrated by the user, 

the respective association of the certificates with each of the The user of the mobile device 302 can access the device's 

accounts therein. account 324 in the proxy server 114 using the mobile device 

It has been described that it takes a noticeable length of 302 that is equipped with a HDML browser. Knowing the 
time in a regular full-power desktop computer to obtain a URL of the account, the user depresses a predetermined key 
certificate from a CAand generate a pair of keys; private and 35 to cause the chent module 332 to send a request comprising 
public keys therefor. To minimize the latency of obtaining a the URL and the device ID 316 to UDP interface 336 that 
certificate with a mobile device, a certificate manager mod- subsequently establishes a communication session to the 
ule (CMM) 342 maintains a certificate database, preferably proxy server 114 using the HDTP. The request is received by 
in the database 328, to reserve a list of undesignated but the corresponding UDP interface 128 in the proxy server 114 
issued certificates, referred to as free certificates, from one 40 and carried out by the server module 340 to see if the device 
or different CAs. Whenever a user account is created to ID is authorized. The proxy server 114 then acknowledges 
activate a mobile device that requires one or more certifi- the request with a response sent to the mobile device 302 for 
cates to access certain web servers requiring a certificate, a usemame and password. It should be noted that the response 
certificate request (certRequest) signal is sent lo the CMM does not request from the user a pair of username and 
342 to fetch needed certificates from the certificate database. 45 password to permit an access to the account, in fact the 
Upon receiving the fetched certificates from the certificatel permission to access to the account has been granted by 
database, the CMM 342 assigns the certificates to the matching the device ID 316 in the request from the mobile 
particular account by attaching the device ID 316 and otherj device 302 and the stored device ID of the account 320 in the 
account information, hence the fetched certificates become proxy server 114. Instead, the response allows the user to 
associated to the particular account and are placed in the so self-provision the account by entering a pair of new user- 
certificate list 320. Meanwhile the CMM examines the name and password. Once the account 320 receives the pair 
number of the free certificates available in the certificate of new usemame and password, the account, i.e. the user 
database, if the number is below a value, for example 200 info 322, is updated. After the self -provisioning procedure, 
certificates, referred to as threshold, the CMM calls the the user may use the PC 314 which has preferably a 
HTTP module 330 to establish a connection to the appro- 55 sufficient computing power and equipped with a more 
priate CA via the landnet 104 to obtain new free certificates familiar HTML browser to establish a communication ses- 
to fill up the certificate database till the level of the threshold sion using HTTP and the URL lo the account. The newly 
is reached, as such there are always sufiBcient free certifi- provisioned usemame and password are entered in the PC 
cates available in the certificate database to supply any new 314 when prompted and sent over in a packet format to the 
accounts with the ready-to-use free certificates. 60 proxy server 114 using HTTP in which the HTTP server 330 

It can be now appreciated by those skilled in the art that extracts the username and passwond and the server module 

the present invention uses the computing power in a proxy 340 performs an authorization check with the user info 322 

server to carry out the task of obtaining certificates in the memory. If the entered username and password are 

asynchronously, apart from the tradition of obtaining cer- matched, the authorization is granted so that the user or the 

tificates in local devices that nonmally have sufficient com- 65 PC 314 is permitted to access the account 324. The user can 

puting power, and further, unlike the tradition of physically now request a certificate from a specified CA and updates the 

storing the certificates in the local devices, the present certificate Ust 320 and the key list 326. The process of 
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obtaining a certificate from a CA using an HTML browser 
is known to those skilled in the art and therefore is not to be 
described herein. It can be appreciated that, besides the 
capabilities provided by the CMM, the self-provisioning 
capability allows a user to tailor the certificates to his own 
needs while still relying on the proxy server to keep all the 
certificates designated to the mobile device 302, 

Based on FIG. 3, FIGS. 4A and 4B demonstrate an 
example in which the user of the mobile device 302 requests 
certificates from user-specified CAs. After a predetermined 
key is pressed, the mobile device 302 uses HDTP to make 
a request to connect to the proxy server 114 using the URL 
of the account designed to the mobile device: 30286123456- 
10900_pn.mobile.xyz.net. The device ID 86123456-10900 
is extracted from the request and verified that there is an 
account 324 indexed by the same device ID 86123456- 
10900. Upon the verification, the user of the mobile device 
302 is prompted for a set of usemame and password. It has 
been described that usemame and password are not the 
required information for the mobile device 302 to access the 
account 324, rather the user is given a permission to admin- 
istrate the usemame and password. If the user does not enter 
any new usemame and password, the usernamc and pass- 
word in the user account 324 stays the same. If the user 
enters a set of new username and password, for example; 
username-"smith", and the password-"123456", the 
account 324 is updated with the new username and pass- 
word. The user can now go to any computer in the landnet 
104 to manipulate the account 324. The PC 314 is equipped 
with a HTML browser providing a fall graphical user 
interface that allows the user to manipulate the accoun t 324 
much more efficiently. The PC 314 establishes an HTTP 
connection using the URL, for example, mobile.xyz.net, of 
the gateway 354 in the server module 340 to all the user 
accounts in the proxy server 114. The user is prompted at the 
PC 314 for a set of usemame and password. The user must 
enter "smith" for the usemame and "123456" for the pass- 
word to get through the gateway 354. Upon receiving the 
entered username and password, the gateway 354 compares 
them with the ones in the account 324. If there is a mismatch, 
the PC or the user is not permitted to access the account 324. 
If the entered username and password match the ones in the 
account 324, the gateway 354 grants permission to the PC 
314. The user of the PC 314 can now use the HTML browser 
to request special certificate from a special CA 358 by 
providing a URL thereof and place the certificate the account 
324 for the mobile device 302 to use. 

According to one embodiment of the present invention, 
the certificate list may be implemented as a pointer to a 
certificate table 368. As is shown in FIG. 4B, it can be 
appreciated to those skilled in the art that the use of pointer 
provides flexible capacity of the certificate list. The certifi- 
cate index 370 provides a space to store all the certificates 
and the corresponding URL list 372 associated URL for the 
specially requested certificates in the certificate index 370. 
There are a few service web sites that accept certificates 
from certain CAs. For example, a financial web site identi- 
fied by www.financial.com only takes certificates signed by 
CA SI. By self -provisioning the account, the user can 
specifically request the certificate from CASl and place the 
certificate in the certificate table 368. In a later use, the 
mobile device 302 sends a request to establish a connection 
to www.financial.com. When the request comprising www- 
.financial.com is received in the proxy server device 114, the 
URL is used to retrieve the corresponding certificate, the 
certificate by CA SI in this case. Along with the certificate 
by CA SI, the mobile device 302 can access the web 
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identified by www.financial.com. Generally, the certificate 
382 acquired by the CMM 342 is a generic one acceptable 
to many web sites and not associated with a particxilar URL. 
In other words, the certificate table 368 may have a number 

5 of special certificates, such as referenced by 376, 378 and 
380, specifically requested by the user and one or more 
generic certificates, such as referenced by 382, automatically 
acquired by the CMM 342, 
FIG. 5 illustrates a block diagram of various components 

10 in the CMM 342. As described above, the CMM maintains 
a fixed number of free certificates in the certificate database 
and starts to get new certificates through the HTTP server 
330 from the CA as soon as the number of the free 
certificates in the certificate database becomes lower than 

15 the threshold. Referenced by 402 is a certificate engine that 
manages the operations of other components in CMM 342. 
When the mobile device 302 is activated, the account thereof 
is requested to load with one or more certificates. After a free 
certificate is fetched from the certificate database and upon 

20 detecting that the number of available free certificates in the 
certificate database below the threshold, the engine 402 
triggers the distinguished name generator 404, or DN 
generator, to generate a unique distinguished name for a new 
certificate to be created. 

25 The distinguished name is the standard form of naming in 
the CCITTX.509 standard. A distinguished name comprises 
one or more relative distinguished names, and each relative 
distinguished name is comprised of one or more attribute- 
value assertions. Each attribute-value assertion consists of 

30 an attribute identifier and its corresponding value 
information, e.g. CountryName=US, Organization=XYZ, 
Inc. or OrganizationUnit^XYZ Service Division. The use of 
the distinguished names is intended to identify entities in a 
X.500 directory tree that is now being used to implement 

35 "white pages" for the Internet — a directory of people, 
computers, services, and electronic mail addresses. The 
directory is organized hierarchically: international organi- 
zations and countries are at the top; countries are subdivided 
into states or provinces, which in turn are subdivided in 

40 various ways. A relative disfinguished name is the path from 
one node to a subordinate node of the directory tree. The 
entire distinguished name traverses a path from the root of 
the tree to an end node that represents a particular entity. A 
goal of the directory is to provide an infrastructure to 

45 uniquely name every communication entity in the Internet, 
hence the "distinguished" in the distinguished name. 

To ensure that the distinguished name generated by the 
distinguished name generator 404 is associated eventually 
with a user account, the distinguished name prefix generator 

50 406 generates a prefix for the distinguished name. The prefix 
is generally a concatenation of a timestamp and a subscriber 
ID, for example, 861765228-9, wherein the timestamp indi- 
cates when the certificate request is made and the subscriber 
ID is to be assigned to a mobile device when it is activated. 

55 With the prefix from the distinguished name prefix generator 
406, the distinguished name generated from the distin- 
guished name generator 404 must be unique. In order words, 
each of the free certificates in the certificate database has its 
own name and all the names must be distinguished. 

60 The Certificate Engine 402 then invokes the key pair 
generator 412, or KP generator, to generate a pair of public 
and private keys. It does so by using a set of library functions 
which generates the private key based on the public key that 
is generated with supplied seed information. To conform to 

65 the industry standard, the set of library used in the key pair 
generator 412 is supplied by RSAData Security, Inc. having 
an address of 100 Marine Parkway, Suite 500, Redwood 
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City, Calif. 94065. The generated keys are generally in the 
form of a seqneace of binary numbers, such as 
1110101100001 . . . 00101 and unlikely to be duplicated 
without knowing the source to generate them. To generate a 
pair of unique private and public keys, a random number, as 
the source, must be provided according to the set of library. 
It is understood to those skilled in the art that there are many 
ways to get the random number. One of the commonly used 
methods is to generate the random number through a one- 
way hash function from a noise source that may be hard- 
coded or from network traflSc information. The one-way 
means that it is significantly easier to perform in one 
direction (the forward direction) than in the opposite direc- 
tion (the inverse direction), which makes it unlikely to 
derive the private key from the public key. One example of 
such hash functions is to multiply a value itself a certain 
number of times and followed by a modulo operation. 

The certificate engine 402 creates a new entry for the 
certificate in the certificate database and the corresponding 
private key from the key pair is stored in the new entry, 
meanwhile the certificate engine 402 uses the generated 
distinguished name and the public key obtained from the key 
pair generator 412 to generate a certificate signing request or 
CSR. The CSR is a public standard format for requesting 
certificates from a CA. The CSR contains, among other 
things, the public key that is to be certified by the CA and 
the distinguished name associated with the public key. The 
CSR is a binary block of data packaged in a certificate 
request in a standard form that is then sent to the CA through 
the HTTP module 330 using HTTP. 

Upon receiving the certificate request, the CA verifies the 
supplied information therein and attests to the validity of the 
user's public key along with other information by signing 
the certificate. The CA then issues a certificate response, 
which may contain the signed certificate or an error. If the 
certificate response contains an error, that means the certifi- 
cate being requested fails, a new process must be restarted. 
When the certificate response comes back fi:om the CA, the 
certificate engine 402 extracts the distinguished name from 
the received certificate and updates the corresponding entry 
in the certificate database through the certificate storage 
library 408. At this point that entry contains the signed 
certificate which has the public key embedded in it and the 
corresponding private key, which has been referred to as the 
free certificate. 

When the mobile device 302 is activated, a request is 
submitted for creating a certificate for the device. The 
certificate engine 402 fetches a free certificate from the 
certificate database and associates it with the device ID. The 
association is performed by making an entry in a separate 
temporary table called devicc_cert_jnap_tbl, preferably in 
a RAM of the proxy server 114. 

The certificate storage (CS) library 408, or CS library, is 
used to administrate the certificate database and from time to 
time receives certificate revocations lists from CAs. A cer- 
tificate revocation list (CRL) is a list of certificates that have 
been revoked before their scheduled expiration date. There 
are several reasons why a certificate might need to be 
revoked and placed on a CRL. For instance, the key speci- 
fied in the certificate might have been compromised, or, the 
user specified in the certificate may no longer have authority 
to use the key. To be more specific, a user name associated 
with a key is "Mr. Smith, Vice President, XYZ Corp." If Mr. 
Smith left the company, the company may not want him to 
be able to sign messages with that key, and therefore, the 
company would place the certificate on a CRL. When 
verifying a signature, one can check the relevant CRL to 
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make sure the signer's certificate has not been revoked. 
Whether it is worth the time to perform this check depends 
on the importance of the signed document. The CRL is 
maintained by the CA and provides information about 
revoked certificates that were issued by the CA The CRL, 
however, only lists current valid certificates, since expired 
certificates should not be accepted in any case; when a 
revoked certificate is past its original expiration date, it is 
removed from the CRL. Although a CRL is maintained in a 
distributed manner, there may be central repositories for a 
CRL, that is, network sites containing the latest CRLs from 
many organizations. 

The certificate library 408 receives such CRL and informs 
the certificate engine 402 to take action when any certificates 
maintained by the CMM 342 is in the list. It is described that 
the CMM 342 maintains a certificate database housing a 
fixed number of free certificates. When the CMM 342 
associates a certificate from the certificate database to a user 
account, the associated certificate must be valid. This is 
guaranteed by first consulting with the CRL through the CS 
library 408. If a fetched certificate from the certificate 
database is somehow on the CRL, the fetched certificate is 
discarded and a next certificate is fetched from the certificate 
database. A check-up of the fetched certificate with the CRL 
is always performed in the CS library 408 before the fetched 
certificate is associated to the account. It is understood to 
those skilled in the art that the check-up with the CRL may 
be performed by an exhaustive comparison. The time or 
computation it takes to do the check-up regardless of the 
length of the CRL is affordable as all are being carried out 
in the proxy server 114 asynchronously with the mobile 
device 416. 

According to one embodiment of the present invention, 
the source code listing in the appendix demonstrates opera- 
tions in the CMM. The main( ) function creates a 
TCertEngine object and calls initialized by a function named 
Initialize which creates the necessary threads to service 
HTTP client based requests. It also creates threads that 
monitor certificates in the certificate database. When the 
thread is created it monitors available resources and calls 
GenerateCert in TCertHttpProto to create certificates. This 
thread uses TDBCertPool to create a new entry in database 
for the certificate pool. 

The function GenerateCert gets a new Distinguished 
Name from the Distinguished Name Generator. It also gets 
a new public/private key pair from the Key Pair Generator. 
GenerateCert used this information to construct a CSR, It 
then issues a request to a CA over HTTP using SendCSR 
method in THttpCertRequest. When the certificate response 
comes back from the CA, it updates the entry in the free pool 
using TDBCertPool. 

When a free certificate needs to be associated with a user 
account, the HandleCreateCert method in TCertCreateCall- 
back is invoked. This method extracts a new certificate from 
the free certificate pool using functions in TDBCertPool. 
The method then calls functions in TDBDeviceMap to make 
a new entry in the device_cert_jnap_tbl. It then returns a 
response to the caller. The Reissuer thread, 
TCertReissueThread, calls ReissueCert in TCertHttpProto to 
have certificates reissued. It calls methods on TDBCertPool 
to TDBDeviceMap to revoke certificates m the free pool and 
those that are associated with the device. 

FIGS, 6A and 6B illustrates an operational flowchart of 
the centralized certificate management system in the present 
invention and should be understood in conjunction with 
FIGS. 3 and 4. Complied and linked processes of the present 
invention are loaded into a proxy server 502 and cause the 
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proxy server 502 to perform the centralized certificate 
management. It is understood to those skilled in the art that 
a proxy server is a server computer or device, generally 
equipped with sufficient computing power and memory, that 
is loaded with applications that cause the device to service 
other computing devices, hence the applications therein are 
commonly referred to as the server and the device itself is 
referred to herein as server device. The computing devices 
in the present invention are the thin devices that may be 
mobile devices, cellular phones and the Internet appliance 
controllers. 

At 504, the CMM 324 cause the server device 502 to 
maintain a certificate database that is preferably stored in a 
local storage driver in the server device 502. The certificate 
database reserves a fixed number of free certificates signed 
by a CA yet to be associated to a user account or a thin client. 
By maintaining the ready-to-use free certificates in the 
database, the thin client can get a certificate associated 
thereto without a noticeable time delay, needed computing 
power and memory. At 506, the number of the available free 
certificates is examined. If the number drops, a process to get 
new certificate starts at 510. It should be understood that the 
number of the free certificates in the certificate database is 
dropped sometime because of the certificate updating at 508. 
To ensure that the certificates to be associated with user 
accounts are always valid, the CS library 408 constantly 
updates the free certificates in the certificate database 
according to a certificate updating message received from a 
CA or commonly used repository site. The certificate mes- 
sage may comprise a CRL or insert/delete query, which 
causes the CMM 324 to discard some of the free certificates, 
hence the number of the free certificates decreases. In any 
case, the CMM 324 tries to maintain the level of the free 
certificates in the certificate database by getting new certifi- 
cates from a CA. When the process to get a new certificate 
starts, the CMM 324 first gets a distinguished name for the 
new certificate by calhng the DN prefix generator 406 and 
DN generator 404 at 510 and 512 and then calls KP 
generator 412 to generate a pair of private key and public 
key therefor at 514. A certificate request is formed at 516 to 
include a CSR comprising the generated distinguished name 
and the pubUc key. At 518, the CMM 342 communicates 
with the CA using HTTP through the HTTP server 330. 
Upon receiving the certificate request, the CA attests to the 
validity of the public key along with other information by 
signing the certificate and returns a certificate response to 
the CMM 342, thus a signed certificate is created at 520. The 
signed certificate is deposited as a firee certificate to the 
certificate database at 522. Logically the number of the free 
certificates is incremented by one and compared with the 
fixed number or threshold. If the incremented number is stUl 
below the threshold, the process to get a new certificate is 
repeated from 510 till the number of the free certificate in the 
certificate database reaches the threshold. 

Meanwhile the CMM 342 maintains a pluraUty of user 
accounts at 536, each preferably assigned to one thin client. 
Each of the accounts has one or more certificates exclusively 
associated with the account. When a thin client is activated 
to be serviced by the server device 502, a new user account 
is established therefor at 538. As described before, the user 
account may comprise a device ID, a subscriber ID, user 
info, a certificate list and a private key list. The device ID is 
a piece of information that helps the server device 502 to 
recognize which thm client device it is supposed to service 
and entered when the thin device is activated. The user info 
contains inform regarding the account configuration and the 
services that the thin client needs. The subscriber ID, the 
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certificate list and the private key list are obtained when a 
certificate is associated thereto. At 540, a request to get a 
certificate is made. Upon receiving the request at 542, the 
CMM 342 fetches a valid free certificate from the certificate 

5 database and associates the free certificate to the account. 
The present invention includes a method of self provi- 
sioning. Specifically, a tiser may attempt to self-provision as 
illustrated at step 544 in FIG. 6B. First, the attempts to 
access a user account by logging onto the account. If the user 

10 is logging in using the thin client device that has a device ID, 
the access is quickly authenticate. If the user is logging in 
using a PC connected to the Internet, then the user must enter 
the current usemame and password. After obtaining access, 
the user may change the username and/or password at step 

15 572. The user can then access the account from the thin 
client or another computing device to request a certificate 
from a user-specified CA at 578. 

After the thin client is activated by establishing the 
account having one or more certificates in the server device 

20 502, it is now possible for the thin client to establish secure 
and authenticated communication session with some secure 
web sites to conduct private communication therebetween. 
At 550, the server device 502 receives a session request from 
the thin client to establish a secure and authenticated com- 

25 munication session with a web site identified by a URL. The 
session request comprises the device ID of the thin client in 
order for the server device 502 to recognize the thin device 
and consequently authorize such request therefrom. At 552, 
the device ID is extracted from the session request and 

30 compared with the device ID in the user account. If the 
devices IDs are matched, the thin device is authorized and 
further examined per the corresponding account thereof. At 
544, the certificate in the matched account is fetched to be 
included in the session request that is sent to the desired web 

35 site using HTTPS. At 558, an authentication between the 
thin client and the contacted web site is carried out by 
examining each other's certificate. If each certificate is 
trusted, a session key is resulted therefrom and used to 
encrypt information to be exchanged between the thin cUent 

40 and the web site, hence a secure and authenticated commu- 
nication is established. 

The present invention has been described in sufficient 
detail with a certain degree of particularity. It is understood 
to those skilled in the art that the present disclosure of 

45 embodiments has been made by way of example only and 
that numerous changes in the arrangement and combination 
of parts as well as steps may be resorted without departing 
from the spirit and scope of the invention as claimed. 
Accordingly, the scope of the present invention is defined by 

50 the appended claims rather than the forgoing description of 
embodiments. 
What is claimed is: 

1. A method for managing centralized certificates in a 
proxy server device for a plurality of thin chent devices 
55 coupled to said proxy server through a data network, the 
method comprising: 

maintaining a free certificate database accessible by said 
proxy server, the free certificate database comprising a 
plurality of free certificates issued by a Certificate 
60 Authority (CA) wherein each of the free certificates has 
a corresponding public key and a corresponding private 
key; 

maintaining a user account database wherein said user 
account database is not a thin client device, said user 
65 account database accessible by said proxy server that 
performs communication on behalf of said thin client 
devices, said user account database comprising a plu- 
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rality of user accounts, each of the thin client devices 
associated with one of said user accounts wherein each 
of the user accounts comprises a device ID, a list of 
public and private keys assigned to the user account, 
and a list of certificates assigned to the user account; 
and 

adding a certificate taken out from the free certificate 
database to each of said plurality of user accounts in 
said user account database. 

2. The method as recited in claim 1, further comprises 
receiving a certificate request when the number of free 

certificates in the certificate database is lower than a 
low threshold number; and 
generating a new certificate wherein generating the new 
certificate comprises, 

generating a distinguished name for the new certificate; 

generating a new private key and a new public key for 
the new certificate; 

sending a certificate request to the CA wherein the 
certificate request comprises the generated new pub- 
lic key; 

receiving the new certificate signed by the CA; and 
depositing the new certificate in the free certificate data- 
base. 

3. The method as recited in claim 1, wherein maintaining 
the user account database comprises: 

retrieving one of the free certificates from said free 
certificate database when a new thin client device is 
activated; 

establishing a new user account comprising a new device 
ID and a new subscriber ID; and 

associating the retrieved free certificate and the corre- 
sponding private key and public key with the new user 
account having the new device ID. 

4. The method as recited in claim 1 further comprising: 
updating the free certificates in the free certificate data- 
base upon receiving a certificate updating request. 

5. The method as recited in claim 4 wherein updating the 
free certificates in the free certificate database upon receiv- 
ing the certificate updating request comprises removing an 
invalid certificate from the free certificate database when the 
certificate updating request is a certificate revocation list. 

6. The method as recited in claim 1 further comprising: 
updating a user account in the user account database 

associated with a valid device ID upon receiving a 
newly provisioned usemame and password from a thin 
client device having said valid device ID. 
1. The method as recited in claim 3 wherein the updating 
the free certificates in the certificate database upon receiving 
the certificate updating request comprises deleting a certifi- 
cate from the certificate database according to an insert/ 
delete query in the certificate updating request. 

8. The method as recited in claim 1 wherein a user accoimt 
in the user account database may be accessed from a 
computer coupled to said proxy server through the global 
internet. 
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9. The method as recited in claim 8 wherein a valid 
usemame and password must be supplied to access said user 
account, 

10. An apparatus for managing centralized certificates in 
5 a proxy server device for a plurality of thin client devices 

over a data network, the apparatus comprising: 

a certificate manager module for generating free certifi- 
cates; 

a free certificate database coupled to the certificate man- 
ager module for storing the free certificates from the 
certificate manager module until reaching an upper 
threshold; 

a user account database, said user account database not 
stored in a thin client device, said user account database 
accessible by said proxy server device that performs 
^ communication on behalf of said thin client devices, 
said user account database comprising a plurality of 
user accounts, each of the thin client devices associated 
with one of said user accounts wherein each of the user 
accounts comprises a device ID and a list of certificates 
assigned to the user account; and 

a certificate assigning module for associating one of said 
free certificates in the free certificate database to one of 
said plurality of user accounts in said user account 
database associated with a thin client device. 
25 11. The apparatus as recited in claim 10 wherein the 
certificate manager module comprises: 

a certificate engine communicating with the certificate 
assigning module; 

a name generator generating a unique name for a new 
certificate; 

a key pair generator generating a private key and a public 

key for the new certificate; and 
a certificate request module for contacting a certificate 
2^ authority for the new certificate, wherein a certificate 

request from said certificate request module comprises 

the public key and the unique name. 

12. The apparatus as recited in claim 11, wherein said 
name generator comprises a distinguished name generator 
that combines a timestamp along with a subscriber ID. 

13. The apparatus as recited in claim 10 wherein the 
certificate manager module updates said free certificate 
database upon receiving certificate update request. 

14. The apparatus as recited in claim 13, wherein said 
certificate update request comprises a certificate revocation 
list. 

15. The apparatus as recited in claim 14, wherein said 
certificate update request further comprises an insert/delete 
query. 

16. The apparatus as recited in claim 10 further compris- 
ing: 

a computer network coupled to said proxy server device; 
and 

a client computer coupled to said computer network, said 
55 client computer able to access a user account in said 
user account database. 

If inn m ^ 
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